Presque six années après la précédente version, la 14.2, le 02/02/2022 à 22h22m22s temps universel la Slackware 15.0 est sortie.
Slackware est une distribution Linux, historiquement la plus ancienne toujours active, coiffant Debian au poteau d’un mois exactement (annonces les 16 juillet et 16 août 1993).
L'année prochaine nous fêterons les 30 ans de ces deux projets.
Patrick Volkerding, l’auteur, principal développeur, et seule personne à vivre (via patreon), du projet Slackware, nous livre avec un peu de nostalgie une version difficile mais passionnante à construire, où il reconnaît que le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX, tout en apportant aussi des nouveautés d’une grande qualité.
Sommaire
- Voici d’abord une traduprétation du Changelog :
- Slackware en quelques phrases
- L’alliance entre la tradition et le modernisme
- Bon, mais les vraies nouveautés alors ?
- La maintenance dans le temps
- Le projet Slackbuilds.org : étendre sa Slackware vers l’infini et au-delà
- Être accompagné pour découvrir Slackware
Voici d’abord une traduprétation du Changelog :
Mardi premier février 2022.
4h37 : la voix d’outre-tombe tonne « La grotte est dorénavant fermée… »
5h35 : oups, ma lampe à huile est presque à sec…
Mercredi 2 février.
4h17 : j’en aurai terminé demain…
Le 02/02/2022 à 22h22m22s temps universel la Slackware 15.0 est sortie !
Laissons derrière nous ce cycle de développement bien trop long, avoir eu les yeux plus gros que le ventre ne nous a pas empêché de tout polir à la perfection.
Et espérons en avoir enfin terminé avec les changements les plus tordus, pour que le cycle de la 15.1 retrouve une durée habituelle, grâce au carénage aux petits oignons de l’infrastructure de développement.
Je remercie toute l’équipe de Slackware. Mais aussi toutes les personnes participant au développement des multiples projets upstream dont le travail nous a donné tant de belles pierres pour bâtir le nôtre. Sans oublier tous les gens sur LinuxQuestions.org et ailleurs qui ont testé, proposé, corrigé et nous ont soutenus, pour faire naître cette version.
Je n’aurais rien pu faire sans vous tous, acceptez donc ma gratitude !
Slackware en quelques phrases
- Slackware est la plus artisanale des grandes distributions ;
- elle est réputée pour sa stabilité et sa robustesse ;
- on considère pour diverses raisons qu’elle permet de se familiariser avec l’univers GNU/Linux plutôt qu’un univers Slackware/Linux ;
- le gestionnaire de paquet n’intègre pas de résolution de dépendances ;
- disponible pour ix86, x86_64, arm et bientôt aarch64 ;
- on l’utilise généralement avec KDE ou XFCE. Gnome n’est pas fourni par défaut ;
- non destinée à un usage spécifique, elle s’utilise aussi bien sur un serveur multi-fonction, un poste de travail, ou une machine personnelle ;
- on considère en général qu’elle n’est pas faite pour les personnes pour qui Linux n’est qu’un outil pour faire fonctionner un poste de travail : plus absconse à installer (mais très simple), impose la ligne de commande et l’édition de fichiers de configuration en texte pour son administration, il faut accepter de mettre les mains dans le cambouis.
L’alliance entre la tradition et le modernisme
La caractéristique principale d’une nouvelle version de Slackware n’est pas tant de savoir ce qui a changé, car on peut toujours partir du principe que les dernières versions des logiciels sont embarquées, sauf s’il y a eu des altérations récentes et disruptives.
Ce qui est intéressant est plus de voir ce qui n’a pas changé, ou ce qui a changé sans changement de façon de faire.
Ainsi Wayland ne remplace pas X11, mais est accessible à côté, sans spécialement d’efforts.
Pour l’authentification, PAM remplace le simple et traditionnel fichier shadow, mais en utilisant le traditionnel fichier shadow, donc une mise à jour est entièrement transparente, et libre à chacun de changer de backend d’authentification.
Déjà avec la 14.2 pulseaudio devenait par défaut, mais il était facile de s’en passer, aujourd’hui il est facile de basculer sur PipeWire qui n’est pas par défaut parce que trop jeune encore.
Slackware ne sera probablement jamais basée sur systemd car ça chamboulerait toute l’organisation de /etc/, des scripts de démarrage, et ne suit pas la philosophie KISS-Slackware, mais l’utilisation d’elogind à la place de Consolekit permet à certains outils basés sur l’écosystème de systemd de retrouver leurs petits.
On peut noter que la commande python persiste à démarrer python2, même si les outils Python inclus (par exemple Mercurial ) utilisent python3. Un jeu de modules standard est présent pour python2 rendant son utilisation aussi simple et habituelle que ces vingt dernières années. Le reste du système utilise python3 explicitement, et les paquets disponibles sont bien plus vastes.
Le travail de ce côté sur Slackbuilds.org est encore un peu chaotique, mais commence à se stabiliser aussi, avec l’abandon ou le passage en legacy des paquets python2 (le nom devient alors python2-paquet, tandis que paquet est réservé au paquet python3, parfois python3-paquet parce que la cohérence n’est pas encore à l'ordre du jour).
Si on utilise Slackware sur un poste de travail, on continue d’utiliser XFCE ou KDE.
Avec blackbox, fluxbox, fvwm2, mwm, twm et Windowmaker toujours disponibles comme depuis ces vingt ou trente dernières années…
D’ailleurs, à l’installation, il est toujours très simple de ne pas inclure KDE qui prend beaucoup de place (954Mo sur 3.1Go sur l’ISO d’installation).
Probablement, le changement le plus disruptif est d’avoir basculé sendmail dans extra et de l’avoir remplacé par défaut par postfix/dovecot ! Car là il faut changer sa configuration, et apprendre de nouveaux logiciels, mais bon, c’est Slackware, on n’est pas obligé, on peut conserver son sendmail, faut pas déconner non plus.
Et puis la Slackware est toujours disponible pour machines ix86 !
Avec le même arbre de compilation, donc la distribution est intégralement la même sur machine 32 bits.
Comme alliance entre tradition et modernisme, nous avons là un bel exemple.
Côté noyau Linux, les deux mêmes versions sont fournies, la version generic, qui vient avec son vaste lot de modules, et nécessite un initrd pour fonctionner.
Et la version huge qui inclus les modules directement dans le noyau, et permet de démarrer à peu près n’importe quoi.
Slackware 15.0 restera avec le noyau 5.15.19, maintenu sur le long-terme par Greg Kroah-Hartman.
La version -current quant à elle utilisera un noyau plus récent au fil du temps.
La version arm n’est pas à l’identique, il y a quelques différences, mais rien de majeur, et la version aarch64 arrive, tranquillement : une Slackware arrive quand elle est prête et c’est tout.
Bon, mais les vraies nouveautés alors ?
Majoritairement, elles sont invisibles à l’utilisation, et concernent le projet en lui-même.
Slackware a toujours eu ce petit côté artisanal, une équipe réduite et extrêmement motivée, mais fait avec un très grand sérieux. La réputation de stabilité de cette distribution n’est pas usurpée, et les mises à jours qui cassent des choses ont historiquement été très rares, et bien sûr toujours dans la version -current.
Aujourd’hui, il y a un script make_world.sh qui recompile l’intégralité du système à partir des sources. Ça peut paraître logique, ce n’est certainement pas quelque chose de révolutionnaire par rapport à d’autres distributions, mais ça change bien des choses pour le développement de la Slackware elle-même.
Le gestionnaire de paquets a évolué pour permettre des lancements d’installations/mises à jour concurrents, et minimise les écritures pour épargner les disques SSD.
Et comme écrit plus haut, les vrais changements sont rendus invisibles, PAM, elogind, Wayland, QT5, rien ne se fait dans la douleur, on n’a même pas besoin de lire la doc pour utiliser ou mettre à jour depuis la 14.2.
À noter cependant que ce n’est pas le cas de la version ARM, en effet la 14.2 était en soft float et la 15.0 en hard float, le changement a eu lieu il y a plusieurs années dans -current, et les deux ne sont pas compatibles binairement parlant, il faut donc tout réinstaller.
Tout ça va surtout permettre à l’équipe de travailler plus efficacement sur la version -current.
La maintenance dans le temps
La version stable restera figée, avec des patchs, en fin de vie la 14.2 faisait 1252 paquets, et 152 patchs. C’est à dire 152 paquets qui ont été mis à jour au fil de ces presque six années, pour des raisons de sécurité essentiellement. En général le cycle est plus court et il y a moins de patchs.
La faille récente de polkit a été corrigée en même temps que sous Arch, Manjaro, Debian, Redhat et autre, pour la 14.2 et -current.
Firefox, Seamonkey et Thunderbird ont vu plus de mises à jour avec des versions majeures (Firefox est passé de la 45.2.0esr à la 68.12.0esr), mais il s’agit ici de cas très particuliers.
Côté noyau, la 14.2 avait démarré en 4.4.14, et est aujourd’hui en fin de vie avec la 4.4.301.
Ça veut dire qu’il n’y a absolument aucun souci à se faire côté matériel : si ça fonctionne aujourd’hui, ça fonctionnera encore quand la 15.1 sortira.
Donc comme d’habitude, pas grand-chose à dire : maintenir la 15.0 c’est appliquer les mises à jour les yeux fermés, et redémarrer quand le noyau corrige des failles de sécurité.
On l’a dit non ? Le maître-mot c’est stabilité, et ce n’est pas un vain mot ici.
Le projet Slackbuilds.org : étendre sa Slackware vers l’infini et au-delà
Ce paragraphe utilise la première personne, et est écrit par Yth.
Slackbuilds.org ou SBo pour les intimes, est un projet annexe, reconnu il y a quelques années par Patrick Volkerding pour son intérêt et sa qualité, et qui permet d’étendre sa Slackware. La plupart des membres de l’équipe de Slackware elle-même participent à ce projet à l’exception notable d’AlienBob et de Patrick lui-même, qui ont bien assez de travail par ailleurs.
Parce que bon, soyons sérieux, la Slackware c’est cool : stable, solide, respectueux, vaste et complet, et plein de qualités dont je ne saurais me passer aujourd’hui, mais on n’y trouve pas tout ce que je veux, tout ce que j’aime, tout ce que j’utilise.
Point de Sylpheed, PostgreSQL, openSMTPD, SMPlayer, VLC, 0ad, Blender, Warzone2100, audacity, enlightenment, dosbox, endless-sky, flare, freeciv, glewlwyd, glusterfs, inkscape, scribus, haproxy, grisbi, keepassxc, jdupes, Planet Blupi, redis, qemu, virtualbox, ScummVM, syncthing, tor-browser, Unvanquished, transmission, Battle for Wesnoth, wine, youtube-dl…
Bigre, ça a l’air dramatique vu comme ça.
On ne l’a pas dit, mais la Slackware est plutôt abrupte pour les novices, même si beaucoup d’entre nous ont démarré avec cette distribution, et ont appris énormément de choses sur l’univers de Linux grâce à elle.
Mais rien n’est perdu, car avec une base aussi solide, il est très - très - simple de maintenir des scripts permettant de construire ses propres paquets additionnels.
Ces scripts s’appellent des Slackbuilds, ils prennent en entrée les sources d’un logiciel et sortent un paquet Slackware à installer soi-même.
Il y en a presque 5000 aujourd’hui. Tous ne sont pas à jour, mais la majorité, et ceux qui comptent le plus, le sont parfaitement, et vont compiler sans accrocs sur une Slackware stable. Mais bon, au moment de l’écriture de cette dépêche, la notion de stabilité vient de se prendre un grand coup de changement, donc il faut attendre un peu que SBo lui-même se stabilise, même si le travail est largement avancé.
Divers outils existent pour gérer le téléchargement des sources, la création des paquets, la gestion des dépendances, automatiquement.
Mais surtout, ça peut permettre de proposer un dépôt additionnel de paquets binaires pour que l’utilisateur final les installe sans rien compiler, et sans même savoir ce que ça veut dire.
Le projet est entièrement bénévole, et on y trouve vraiment tout ce qu’on cherche. La marche pour participer est petite pour qui sait faire un ./configure && make && make install
: il faut connaître la Slackware, et après on s’inspire des milliers de scripts existants pour faire le sien, un mail sur la liste et c’est parti.
Je maintiens aujourd’hui presque 90 Slackbuilds divers et variés, et pour la majorité d’entre eux la tâche est très simple.
Des scripts récupérés parce qu’un contributeur quitte le projet (dosbox, mon premier il y a 4 ans), d’autres ajoutés parce que j’en avais besoin (sassc maintenant intégré à Slackware 15.0), ou parce que je pouvais le faire : Planet Blupi ou d’autres projets dont on a vu la naissance dans nos colonnes comme Glewlwyd.
De mon expérience, avoir la Slackware stable comme base rend les choses très simples.
Le gestionnaire de paquets sans gestion de dépendance est un atout incomparable.
Même si on doit bien jouer avec ces dernières dans le projet Slackbuilds lui-même, car un paquet n’arrive pas toujours seul (coucou vlc, Blender…).
Si la Slackware stable reste figée, les Slackbuilds, toujours basés sur la version stable et non la version -current (il existe cependant une branche pour ça), sont eux très à jour, et pas du tout figés dans le temps. Le projet est très dynamique avec une sortie toutes les semaines, une fois fusionnées les contributions de chacun.
Aujourd’hui je trouve plus simple de créer un nouveau fichier slackbuild lorsque je veux tester un nouveau logiciel non présent dans le projet, et pouvoir l’installer dans le système comme n’importe quel autre paquet.
Être accompagné pour découvrir Slackware
Si tu ne connais pas du tout Slackware et que cette dépêche t’as donné envie de l’installer mais que tu crains son côté moins prémâché que d’autres distributions aujourd’hui plus répandue, tu pourrais être intéressé par le livre Débuter avec Linux de Kiki Novac qui fait découvrir Linux à travers Slackware 14.2. Pas la dernière version mais pour pas mal de choses sans doute encore valides. Tu trouveras par ici le témoignage d’une moule de LinuxFR qui a apprécié ce livre.
Aller plus loin
- Slackware (200 clics)
- Release notes (19 clics)
- Annonce (21 clics)
- Annonce sur le blog d'Eric 'AlienBOB' Hameleers (38 clics)
- Slackbuilds.org (46 clics)
- Slackware pour ARM (23 clics)
# 15.0 disponible pour ARM aussi
Posté par Yth (Mastodon) . Évalué à 10.
Et ce matin la version ARM est officiellement sortie en 15.0 aussi, une semaine après les versions ix86 et x86_64 !
# Slackware n’intègre pas de résolution de dépendances ?
Posté par Skilgannon . Évalué à 5. Dernière modification le 10 février 2022 à 01:32.
Bien le bonjour,
A part de nom et de ce que montre Adrien dans sa vidéo, je ne connais pas Slackware.
Je ne comprends pas vraiment la phrase « le gestionnaire de paquet n’intègre pas de résolution de dépendances ».
Tel que je le comprend, il faudrait installer et surtout résoudre toutes les dépendances d’un paquet à la main. Par exemple ( et merci cette nouvelle), si je voulais installer « sudo », il faudrait que je cherche sur pkg.org ou autre, non seulement sudo mais aussi que j’installe avant : ibaudit1, libc6, libpam-modules, libpam0g, libselinux1, libselinux1 et zlib1g.
Or dans la vidéo d’Adrien, c'est bien Libreoffice qui est installé et non pas toute la multitude de librairies dont doit dépendre ce paquet. Ce qui bien que un peu casse pieds est acceptable au contraire de l’exemple avec sudo qui est pour moi rédhibitoire.
Plus généralement, je suis sous archlinux depuis pas mal de temps et je cherche à tester une autre distribution ou systeme d’exploitation pour changer 1) Pour l’instant j’avais dans ma liste de test possible NixOS ou des BSD comme FreeBSD/GhostBSD mais du coup pourquoi pas Slackware ? Indépendamment bien sûre de la question posé ci-dessus … et du choix plus que douteux des couleurs dans l’installeur !
1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10.
Je n'ai pas vu la vidéo, mais comme l'indique Wikipédia
Plus précisément
Ça c'est pour une petite nouveauté non mentionnée par la dépêche et pour illustrer le fonctionnement global (et donc montrer ce qui a été fait dans la vidéo pour LibreOffice.) La plupart des gestionnaires de paquet fonctionnent d'une façon un peu similaire.
Maintenant, pour aller plus loin :
Donc, comme les autres gestionnaires de paquets, ce qui est fait est tracé mais dans des fichiers textuels et non une base de données binaire. L'organisation est très simple et on peut tout refaire manuellement… (c'était le cas avant le gestionnaire de paquets : on extrayait l'archive et on faisait les opérations demandées par la procédure d'installation qu'on pouvait automatiser en écrivant soi-même le
doinst.sh
: c'est une distribution qui se veut sans artifice et est idéale pour maîtriser tout ce qui se fait sur le système sans truc auto-magique.) Du coup, ouiIl n'y a vraiment pas de souci pour un paquet officiel (comme pour LibreOffice) : il y a tout ce qu'il faut en général dedans. Quand il y a des bouts de code partagés, l'appli est souvent découpé de sorte à résoudre le souci, comme dans d'autres distributions (on aura par exemple : trucmuche-server, trucmuche-client, trucmuche-tools, trucmuche-common) et la description informe clairement sur les autres dépendances qui ne font pas partie de l'appli (avec sudo, tu auras genre une information qu'il faut : ibaudit1, libpam, libselinux1, et zlib1g …dont la majorité sera déjà installé de base.)
L'absence de gestion de dépendance n'est vraiment problématique que pour des paquets qui ne sont pas empaquetés pour Slackware, typiquement des trucs récupérés aléatoirement sur la toile. Mais même dans ce cas, si c'est bien documenté on ne doit pas rencontré (trop) de souci. Et sinon (jamais eu besoin pour ma part), si ça peut te rassurer :
Comme rien n'est imposé et que c'est fait au plus simple, on peut même fonctionner un peu façon Arch/Gentoo/…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Skilgannon . Évalué à 2.
Merci pour la réponse complète, elle m’a éclairé sur pas mal de point.
Pour le reste et pour être sure, il faudra que je teste la distribution.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 10. Dernière modification le 10 février 2022 à 09:00.
Slackware et Debian ont peut-être démarrée en parallèle, mais ces deux projets sont très différents.
Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».
Les paquets Slackware sont séparés en catégories, par exemple :
k - les sources du noyau Linux fourni par ailleurs ;
kde - tout KDE
xfce - tout XFCE
t - texlive
x - X.org / Wayland
xap - outils nécessitant un serveur graphique
n - outils réseau (apache, dovecot, dhcp, …)
etc.
Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)
Bref, pour installer sudo, une fois que tu as installé ta Slackware, ben tu ne fais rien, c'est dispo, tu ne tires pas de dépendances, tu ne cherches pas, c'est là, ça fonctionne.
Le seule question qui se pose, c'est quid des logiciels qui ne sont pas disponibles.
Et là tu as Slackbuilds.org, qui va te présenter la liste des dépendances, et si tu utilises un outil type sbotools, il va construire les dépendances, les installer et tout te faire jusqu'à ton paquet final.
À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).
Tu as donc le mauvais côté de la non gestion de dépendances : tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)
Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.
Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.
En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.
Ça veut dire que tu peux parfaitement faire n'importe quoi et tout péter.
C'est ce que j'attends de mon système d'exploitation : qu'il me laisse tout casser si c'est ce que j'ai envie de faire !
D'ailleurs, fais gaffe, sous Slackware, un « rm fichier » ne te demande pas confirmation, tu n'es donc pas obligé de toujours écrire « rm -f fichier », et donc si « fichier » est protégé tu auras un avertissement visible, rare, et qui t'évites de faire des bêtises.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Renault (site web personnel) . Évalué à 4.
Le problème n'est pas le mécanisme des dépendances, c'est le découpage des paquets qui n'est pas assez fin.
Slack ne résout aucun problème en ce sens, si le paquet est mal fait, tu as le même problème, et si ta distribution avec dépendances gérées fait n'importe quoi il faut blâmer le mainteneur et pas le concept des dépendances automatiquement résolus.
Mouais, je ne vois pas l'intérêt de la liberté de facilement faire de la merde. Je comprends l'intérêt du minimalisme et de ne pas avoir trop de restrictions, mais bon si c'est trop au détriment de l'utilisabilité ou juste pour pouvoir faire n'importe quoi mais rien de bien utile ne plus, je ne comprends pas l'intérêt.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 10.
(Je préfère écrire Slackware en entier pour ne pas confondre avec Slack)
Si, justement : les paquets n'ont pas ces découpes fines.
Le choix de Debian c'est de tout découper finement : un paquet serveur, un paquet client, un paquet pour le dev, un paquet pour la doc, un paquet pour autre chose.
Et puis à partir d'une seule source construire plein de paquets, gérer finement les dépendances, et n'installer que ce qui te sert effectivement à quelque chose.
Ce qui a une très claire utilité pour un serveur le plus minimaliste possible (ou un conteneur type Docker).
Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.
Le choix de Slackware c'est de ne pas découper.
Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un
./configure && make && make install
.En contrepartie, un logiciel qui a une utilisation texte et une graphique, par exemple emacs, va venir complet même si tu n'as pas d'interface graphique. /usr/bin/emacs-no-x11 va fonctionner mais pas /usr/bin/emacs-with-x11.
Et oui, tu vas avoir tout l'emacs graphique qui ne te sert à rien.
Et c'est pas grave.
Laisse de côté des quelques mégaoctets morts, le reste est plus simple à gérer.
Parce que ce n'est pas forcément de la merde.
Ce n'est pas parce que ce n'est pas de telle ou telle manière que les auteurs d'une distrib ont imaginés son utilisation, que ces façons de faire sont mauvaise.
Oui, tu peux tout casser, mais être root permet de tout casser très très facilement.
Je suis root sur toutes mes machines, j'ai rarement cassé grand chose, mais je vivrais très très mal de ne plus l'être parce que la distrib m'en empêche « pour mon bien » ou « par sécurité » !
Bah voilà : je peux tout casser et tout réparer comme je l'entends, si je veux, ou je veux et comme je veux.
Note bien : je suis très content de la gestion de dépendances Debian ou Redhat, quand je bosse sur des serveurs distants, souvent sous CentOS ces derniers temps, je trouve ça pratique de ne rien avoir à connaître du gestionnaire de paquet et juste faire
yum install bidule
.Mais sur mes machines, ça ne m'intéresse pas du tout.
Dans un conteneur, je ne vois pas l'intérêt.
Bref, c'est une particularité de Slackware, que j'apprécie à sa juste valeur, avec ses bons et ses mauvais côtés (je préfère gérer les mauvais côté de Slackware que ceux de Debian, question de goût), et je pense qu'il est important de le préciser parce que ça fait une grosse différence avec toutes les Debian/Redhat.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Renault (site web personnel) . Évalué à 5.
J'installe rarement des paquets après l'installation de ma machine, si je dois l'installer c'est parce que je 'lai découvert et qu'il n'était pas déjà de base dans le système.
Avec Slackware, c'est la même chose, tu découvrir un logiciel sympa pas déjà présent, tu dois le télécharger et l'installer…
Pour que Slackware fasse ça, ils doivent avoir les dépendances de développement installés, dont des bibliothèques graphiques. ;)
En fait tout le travail est fait, mais il manque l'étape du "on met dans la doc qu'il faut installer X" à "on installe X quand on veut Y automatiquement"… Le plus chiant est presque fait pour eux en fait.
Bah justement, c'est utile pour construire le conteneur avec le minimum d'outils en un minimum d'étapes.
C'est comme tu veux de toute façon, mais je cherche la plu valu c'est tout.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 7.
Les dépendances de développement viennent directement avec la compilation/installation depuis les sources.
En fait il faut faire un traitement spécifique manuel pour ne pas les inclure dans ton paquet.
La Slackware est un ensemble complet et fonctionnel, si tu l'installes alors tout fonctionne dedans et tu as tout ce dont tu as besoin pour que tout fonctionne dedans.
Ce (gros) bloc de base je l'aime bien parce que ça me simplifie la vie pour tout le reste : ce qui n'est pas inclus dans Slackware. Et j'aime l'équilibre : il y a beaucoup de choses mais pas tout et n'importe quoi, suffisamment pour faire presque tout ce que tu veux avec ta distrib sans rien ajouter, mais pas les besoins les plus spécifiques, ni toutes les alternatives possibles.
Tu as Apache mais pas Nginx (ni thttpd, ou darkhttpd, etc.), ergo tu as un serveur web, mais pas toutes les alternatives possibles.
Par exemple, je préfère utiliser PostgreSQL à MariaDB, or c'est MariaDB qui est inclus dans Slackware, mais installer PostgreSQL c'est un unique Slackbuild sans aucune dépendance.
Or PostgreSQL a besoin de la glibc, readline, zlib, libxml2, libxslt, openssl, perl, python et tcl.
Ces dépendances sont tellement utiles et standard pour un système Linux qu'elle sont juste là, tu n'as pas à chercher plus loin.
Et donc, si j'ai une Slackware complète (ou que j'assume mon choix de sélectionner mes paquets à la main, comme je le faisais il y a 20 ans - oui je compilais mon noyau paramétré aux petits oignons aussi pour chacune de mes machines), j'ai simplement à vérifier les dépendances des Slackbuilds (à 92% 0, 1 ou 2 paquets, automatisé par les outils de build type sbotools), alors la gestion de dépendances dans le gestionnaire de paquets ne me sert à rien, elle ne m'apporte rien.
Je suis d'accord qu'elle est utile pour construire un conteneur from scratch (une CFS ? 😀), mais dans le conteneur produit, c'est inutile, donc un autre moyen de générer ce conteneur pourrait remplacer un gestionnaire de paquets avec dépendances.
Pour moi c'est la plus-value de la gestion de dépendances en dur qui m'échappe dans la majorité des situations.
Et quand on voit l'enfer des autres systèmes de paquets avec gestion de dépendances complexes, type npm, composer, ou pip, et le bordel qu'ils provoquent, je ne suis pas sûr qu'il faille trop pousser le concept.
Cela dit je ne crois pas que ce genre de problèmes soient présents avec yum ou apt.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Bien expliqué.
D’ailleurs je trouve le découpage à la lime à beurre de Debian un peu énervant.
Tu installes un soft, mais non t’as pas tout le soft, et faut que tu devines parfois le ou les paquets qu’il faut que tu installes en plus pour avoir le soft complet (et non c’est pas toujours -dev)
Sous ArchLinux je trouve le compromis intéressant. Les softs sont en général empaqueté en un seul paquet. Par contre les dépendances sont multiples :
- obligatoire
- optionnelles
Et les optionnelles peuvent par exemple indiquer des trucs qui peuvent apporter des choses sans pour autant empêcher le soft de fonctionner.
git
sous ArchLinux vient avec tout compris (les man pages, les trads, . Par contre si on essaye de lancergitk
sans avoir installé les dépendances optionnelles, ça ne marche pas. C’est parce quetk
est une dépendance optionnelle degit
. Heureusement car sinon sur un serveur on tirerait tout X. Idem pourgit gui
qui dépend detcl
ettk
.Faire des paquets séparés pour des entêtes ou des man pages, c’est complètement con. Ça quasi gagne rien en place disque et ça fait chier quand on n’a pas les paquets. En plus ça doit compliquer les mainteneurs de paquets.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par barmic 🦦 . Évalué à 6.
C'est rigolo j'ai toujours entendu l'inverse comme critique de Debian que le découpage était trop large, qu'il installait trop de dépendances, que le choix d'installer par défaut les dépendances recommandées c'était bloated.
Je ne comprends pas du tout la critique pour git. Par défaut le comportement est exactement celui que tu indique. Tu peux installer les paquets suggérés pour avoir plus ou ne pas installer les paquets recommandés pour avoir moins.
Hum ? Les mainteneurs sont très bien placés pour savoir si ça complexifie leur tâche. En soit pour ce genre de paquet c'est tout automatisé donc je pense que ça ne leur change rien et comme pour toi utilisateur ça ne change rien non plus (même si tu veut faire une installation sur une machine non connectée à internet apt pourra récupérer tous les paquets pour toi et dpkg les installera aussi facilement).
A part une critique de principe parce que tu comprends pas pourquoi ils travaillent comme ça, je ne vois pas ce que ça te fais à toi utilisateur ?
Bon ensuite si on regarde de plus prêt, le paquet
git
a un build par architecture alors que le paquetgit-man
est all architectures donc :Évidement si tu supporte une ou 2 archi (sans jugement moi je n'utilise que amd64, j'ai pas de besoin que la distribution que j'utilise tourner sur sparc) ou que tu fais de la distribution source avec un build à l'installation, tu fera peut être des choix différents.
évidement on parle là 15Mio pour git mais si tu le fait pour chaque paquet tu peut avoir des gains substantiels ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Arf, je ne fais de « full install » que sur mes VM de test. Mon vieux portable Pentium sur lequel tourne Slackware a été installé en choisissant paquet par paquet et non par catégorie. ;-)
À noter que la Debian permet aussi ce genre de chose : n'installer que certaines catégories (mais il y en a moins à l'installation, et plus quand on lance le gestionnaire de paquets en clicodrome) ou choisir les différents programmes (bon ça fait des lustres que je n'ai pas pas essayé et je ne sais pas si ça existe toujours, par contre on n'avait pas la liste de tout ce qui était possible mais juste un petit sous-ensemble que je pense issue des catégories disponibles à l'installation.)
La découpe des paquets est une chose et la gestion des dépendances une autre. Dans l'exemple que tu prends, il se trouve que les distributions Red Hat découpent aussi en gros, comme Slackware, mais avec la gestion de dépendance en plus : ça aide pour les usages domestiques (et les admins qui ne veulent pas avoir le temps de lire toute la doc de ce avec quoi le programme fonctionne et mettre les mains dans le cambouis pour lier les composants) en t'installant en plus le X.org ou le Qt5 etc. (du coup, quelques paquets on été revus pour être découpé en variante avec ou sans X, mais pas aussi finement que chez Debian)
Une distribution est une philosophie/approche de l'administration système et autres facilités. La philosophie Slackware est d'être dans l'esprit des Unix initiaux (d'où la comparaison souvent avec les BSD) où les administrateurs font tout eux-même (à la mano, à leur sauce et non en se voyant imposer une vision) y compris pour les paquets (on récupère la totale telle que conçue par le projet puis on configure ce qu'on veut utiliser et on laisser le reste moisir à côté, là où les autres distributions veulent vous aider à tout prix.)
Ça rejoint ce que je disais dans un autre message. Hormis les gens qui poussent le bouchon trop loin comme moi, il faut prendre le temps de regarder les dépendances pour les gérer mais on rarement une multitude (jusqu'à deux en général et aucun plus souvent, comme tu le montres)
À l'usage, ça marche tellement simplement que tu te demandes parfois si les autres distros Linux n'ont pas inutilement compliqué… (mais je ne crois pas non plus parce-que certains choix amènent fatalement à plus de complexité)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Skilgannon . Évalué à 1.
Pour le coup je suis plus la philosophie Debian ou que même ArchLinux, qui est, il me semble encore plus extrémiste que Debian sur ce sujet.
Dans mes vieux souvenirs quand on installe une Debian « bureau », certain logiciels qui ne sont pas liés à l’environnement de bureau sont aussi installés par défaut. Par exemple, comme sur Slackware visiblement Zenmap.
Que l’on installe Thunar ou Nautilus ok, c’est lié aux environnements mais Zenmap ?
En poussant le bouchon un peu trop loin (comme Maurice), ca m’étonne que qu’il ne soit pas possible d’installer seulement LibreOffice-Writer et Calc sans base ,draw , impress et math. Logiciels dont on se sert presque jamais sur son poste personnel.
Et à l’inverse gnome-tweaks n’est pas inclus dans le meta-paquet Gnome (c’est pourtant un logiciel pour parametrer Gnome …) -_-"
Pour les serveurs, je ne suis pas encore aller fouinner dans les paquets qui sont installé par défaut mais j'ai remarqué assez recaement que Cockpit l'était sur tout les CentOS et dérivés.
Je pense pas qu'il soit compliqué de faire
yum/dnf install cockpit
.Car oui, il n'est quand même pas activé par défaut ouf!
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 4.
Zenmap fait partie de nmap.
Tu as zenmap parce que tu as nmap.
Je ne sais pas si Debian découpe en deux paquets pour l'outil en ligne de commande et l'interface graphique, Slackware ne le fait pas.
nmap c'est une commande réseau de base utile, pas pour tout le monde, mais néanmoins utile de manière générale. Comme dhcp : en réseau domestique tu peux très bien bosser avec des IP fixes, et perdre quelques Mo d'espace disque pour rien…
Découper LibreOffice en ses différentes parties ?
Bigre, c'est possible ? Il n'y a pas un tel socle commun que ça serait super compliqué et/ou sans réel intérêt ?
On peut démarrer LibreOffice-Base et ouvrir un document Writer, un autre Calc, etc.
Je ne crois pas qu'il s'agisse d'outils distincts, mais bien de plusieurs aspects d'un unique outil pour le coup…
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne sais pas si ça a changé, mais sur les sites de OpenOffice et LibreOffice il y avait bien un paquet (
.deb
ou.rpm
) pour chaque composant… Et ce sont bien des outils distincts : un traitement de texte n'est pas un aspect de "[mettre le bon mot]" et un logiciel de présentation un autre aspect ; je peux à titre perso aimer utiliser Writer comme traitement de texte et préférer Gnumeric comme tableur par exemple. Une suite bureautique est bien distribué comme un seul produit mais fait d'un ensemble de programmes dixit Wikipédia, qui précise que certains programmes peuvent ne pas y être (IBM Domino Symphony et Microsoft Office pro incluent un logiciel de messagerie mais ce n'est pas le cas de LibreOffice.)La suite bureautique ne doit pas être confondu avec l'intégré bureautique comme Works qui malgré les apparences enregistre tout dans un format unique (qu'on fasse du traitement de texte ou du tableur dedans ce sera toujours du
.wks
—si j'ai bonne mémoire de l'extension.)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 2. Dernière modification le 11 février 2022 à 14:03.
Je ne dis pas que ça ne devrait, ou ne pourrait, pas être des outils séparés.
D'ailleurs c'est bien plus philosophie UNIX de les avoir séparés.
Mais il y a un binaire soffice.bin qui au bout du compte est appelé par les localc, lobase, lowriter, etc.
Il n'y a qu'un seul logiciel LibreOffice, avec plusieurs modules, qui présentent une interface différente, et servent à gérer des types de fichiers différents, avec des formats différents.
Et ça va même plus loin : si j'ai une fenêtre writer, une autre pour calc, une autre pour base, etc. ouvertes en même temps, je n'ai toujours qu'un seul processus soffice.bin qui tourne, et gère tout ça en parallèle !
LibreOffice n'est pas composé de plusieurs outils juxtaposés.
Et s'il y a des paquets distincts, il doit y avoir énormément de fichiers communs, et un même binaire répété plusieurs fois.
Sauf si - peut-être ? - le code source permet de ne compiler et construire qu'un seul module à la fois, et qu'on peut répéter l'opération pour chacun, et avoir un binaire basé sur le même code source mais qui se restreint à une partie des possibilité.
En d'autres termes : LibreOffice.writer est bien - en pratique - un aspect de LibreOffice, sisi.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Dans la liste des paquets il y en a qui sont communs/mutualisés, et je me souviens d'avoir installé un seul composant dans Debian. C'est en ce sens bien des programmes distincts et il a été prévu de pouvoir les compiler/distribuer séparément.
Mais c'est une "suite" et quelque soit le programme le composant que tu installes, tu auras toujours ton processus soffice.bin (issu du paquet cœur-commun) qui sera lancé pour le gérer. Là dessus c'est mieux fait que du côté µ$ (mais pareillement, à l'époque où on installait la suite depuis un CD, on pouvait sélectionner de n'installer que certains "aspect" et pas d'autres et il n'y avait pas cette symbiose et mutualisation qu'on trouve dans LibreOffice. remarque, pendant longtemps les programmes ont été vendus séparément aussi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 11 février 2022 à 16:51.
En complément à mon précédent message, voir par exemple la page du HowTo de vitux.com avec cette image…
…où on note
libreoffice-core
(c'est lui qui contientsoffice.bin
et d'autres) etlibreoffice-common
(là je crois que ce sont d'autres "ressources" mutualisées —dans/usr/share/
donc) qui sont toujours installés.Pour une utilisation normale/standard, le programme est appelé à travers le gestionnaire, par exemple
libreoffice -writer
. Cela peut faire penser à un « aspect » mais en fait on peut lancer le programme seul, aveclowriter
pour reprendre le même exemple avec des options utiles pour travailler en mode headless.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par jyes . Évalué à 4.
Sauf que "lowriter" est un script qui lance "/usr/lib/libreoffice/program/soffice --writer". À la fin il n’y a bien qu’un seul programme "soffice.bin" qui fait tout tourner. Cependant, les modules (Calc, Base, Impress, etc) contiennent beaucoup de choses dont des bibliothèques. Donc même s’il a y un seul exécutable, il y a bien une distribution binaire différente pour les différents modules. Plus que des « aspects », ce sont de (gros) « plugins ». Mais ça ne me choque pas qu’on distribue les plugins à part, c’est bien l’intérêt de leur modularité par rapport à un exécutable lié statiquement avec tout dedans.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par raphj . Évalué à 10. Dernière modification le 10 février 2022 à 12:49.
Je suppose que tu parles de systemd. Je ne comprends pas cet avis. Ou plutôt, je comprends que c'est une rengaine souvent colportée sans trop réfléchir et une (mauvaise) manière de justifier de la haine contre systemd.
On encense les systèmes BSD pour leur bonne intégration. Justement, systemd c'est un ensemble bien intégré d'outils qui font chacun une chose bien. Ce n'est pas du tout un truc monolithique qui fait tout. Il apporte des qualités à l'écosystème GNU/Linux qu'on prêtait aux *BSD ! :-)
L'init n'est qu'un des nombreux petits outils qui font une seule chose et bien fourni par le projet systemd. Faut voir systemd comme GNU : un ensemble d'outils cohérents. Qui apporte une uniformisation, y compris à travers les différentes distributions, à un bazar pénible et spécifique qui régnait avant son arrivée.
Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.
Si tu éprouves un sentiment aussi fort que l'agacement, c'est que tu as réfléchi sérieusement au problème et que tu vois une autre manière de faire meilleure. Quelle alternative vois-tu ? (en la décrivant précisément, et sans, du coup, tomber sur une description d'un équivalent à systemd).
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 10.
A mon sens, il n'y a aucune haine envers systemd chez Slackware.
Mais comme je l'ai écrit dans la dépêche : c'est très disruptif, il faut changer toute la façon d'administrer sa machine, de gérer les services, d'aller chercher les logs, etc.
Comme tu le dis toi-même : il faut voir systemd comme GNU, et bien Slackware n'est pas une distribution systemd/Linux, mais GNU/Linux.
À la fois par tradition, et parce que ça convient à toute la communauté.
Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.
Ben voilà, sous Slackware t'as tout, mais sans rien de systemd.
Et c'est un choix qui définit autant la distribution que celui de fournir XFCE/KDE mais pas Gnome.
Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.
Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.
Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Renault (site web personnel) . Évalué à 5.
La question est pourquoi ça a été fait comme ça : maintenir des outils en parallèle c'est possible mais pénible, ça demande des efforts d'intégration, de tests, etc. Et à l'ancienne tu avais des scripts init à leur sauce, des astuces qui divergent entre les distributions et logiciels, etc. Les mainteneurs ont globalement sauté sur un outil pratique pour simplifier leur travail.
Si les gens veulent maintenir la méthode à l'ancienne, comme c'est libre ils se mettent en commun pour le faire ou utiliser une autre distribution. ;) Debian et Red-Hat ne doivent pas se plier aux exigences de tout le monde. Les utilisateurs délèguent la gestion de la base du système à ces équipes qui font des choix en permanence, dont systemd.
Donc reprocher que ces équipes ont fait des choix pour les utilisateurs c'est fort le café : c'est le principe même d'une distribution, sinon tout le monde prend une LFS et se débrouille avec.
Mouais pas vraiment.
Le soucis des scripts init à l'ancienne c'est qu'il n'y avait pas de standard.
Tu as certains mainteneurs qui vont gérer des cas courant différemment des autres, voire penser (ou pas) à l'existence de SELinux par exemple, et autres… Du coup tu as plein de manières de faire qui se mélangent, que ce soit au sein d'une distribution ou entre les logiciels eux mêmes quand ils fournissaient leur script init maison.
Du coup là encore, dire que tout est uniforme sans systemd c'est là aussi un peu aberrant, car c'est sans doute l'avantage numéro 1 de systemd.
Le problème est justement le manque d’uniformité et la nécessité de se plonger dedans à chaque fois…
Je ne vois pas quels problèmes Debian et Red-Hat ont spécifiquement introduits mais bon. Ni en quoi les solutions retenues sont moins Linux que les autres.
L'intérêt de systemd ne dépend pas tellement de la distribution en dessous. Typiquement mon projet embarqué est techniquement une distribution sur mesure (on est loin de Red-Hat et Debian) et pourtant il y a systemd et ça a un avantage énorme par rapport à avant. :)
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Yth (Mastodon) . Évalué à 10.
J'avais prévenu que ça partait en troll hein :)
Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).
Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.
Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.
Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend…
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Misc (site web personnel) . Évalué à 4.
Systemd est présent depuis 2 versions de RHEL (cad sur toutes les versions supportés de la distro, sauf pour les clients avec un contrat étendu pour RHEL 6). C'est aussi par défaut dans toutes les versions supportés de Debian, et dans toutes les version d'Ubuntu sauf la 14.04, qui est encore supporté avec un contrat par Canonical.
Donc je pense que depuis le temps, l'argument commence à dire plus sur l'incapacité de s'adapter d'une partie des utilisateurs qu'autre chose.
Et l'exode promise vers les *BSD ne s'est pas vraiment produite.
Je n'ai aucun souvenir de protestations sur le passage d'iptables vers nftables ou pour le changement de ifconfig vers iputils (ou de lilo vers grub, d'un FS X vers un FS Y style zfs/btrfs, etc, etc).
Hop la, tranquille la réécriture de l'histoire.
Pour Debian, il y a eu facile 1 à 2 ans de débats houleux, une période de transition et visiblement, personne n'a été motivé pour maintenir les alternatives, sauf devuan qui ne decolle pas vraiment. On peut comparer les 4000 machines remontées à l'instance popcon de Devuan avec les 210 000 sur l'instance popcon de Debian. C'est quand même 2 à 3 ordres de grandeur plus grand.
Donc on repasseras sur "imposer du jour au lendemain" et "sans douceur".
Pour Fedora, (et donc RHEL/Centos par la suite), ça a aussi été discuté et fait de manière public, via la liste de discussion. Il y a aussi eu des aménagements comme le fait de garder la commande service pendant longtemps, la compatibilité avec les fichiers d'init, le fait que les logs sont restés longtemps dispo via tail comme avant, etc.
Donc on repasseras aussi pour le "sans douceur".
Encore une fois, curieusement, il y a personne qui a crié comme ça pour le passage à Upstart, qui était tout aussi ambitieux en 2006 (fusionner at/cron et init, par exemple) et qui était aussi bien parti pour être mis en place partout (sur Fedora, sur Debian, on avait commencé à en parler pour mageia et aussi sur opensuse, et bien sur, c'était déjà sur Ubuntu).
Et quand je dit "personne n'a crié", je veux évidement dire "à ma connaissance, personne n'a laissé de message de menace sur le répondeur perso d'un mainteneur de Upstart". Je peux pas en dire autant pour systemd, et c'est pas franchement le moment le plus glorieux de la communauté du logiciel libre.
Et je ne sais pas pourquoi, c'est pas le sujet qui ressort le plus quand ça parle de systemd.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par PR . Évalué à 1.
Tu pourrais faire un truc pour moi ? Un truc que j’ai oublié de faire quand je l’ai viré de mon système parce qu’il me tirait encore et toujours plus de dépendances.
Je te laisse deviner l’intrus… qui est de facto un programme de chez systemd :
La même mais avec les programmes systemd, ça donne quoi ?
Mort aux cons !
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Skilgannon . Évalué à 7.
Oula Oula, oui je parle bien de systemd, mais je n'ai pas de haine envers lui ou ces créateurs. J'ai par ailleurs une sainte horreur des extrémistes de tout poile. Et y avoir réfléchi oui sûrement, mais « sérieusement »", ça reste encore à prouver :)
Ceci étant dit, ce n'est pas systemd en lui-même qui m’agace, il est très pratique et s’il a en plus un peu uniformisé le bazar pénible qui régnait je ne peux que applaudir.
En revanche, d'après ce que j'ai compris il s'occupe de la gestion des services et de l'init (qui est grosso-merdo que le fait de lancer des « services » dans le bon ordre (c'est réducteur je sais)). Et pour moi il devrait faire que cela.
Du coup pourquoi, systemd comporte des composants du style
- systemd-logind
- systemd-networkd
- systemd-resolved
- systemd-timesyncd
En quoi ces composants sont de la gestion de services ?
Ou alors je n'ai pas compris ce que était systemd.
Si c'est un environnement, au sens « environnement de bureau » par exemple, alors je viens comprendre cela, mais dans ce cas je voudrais pouvoir ne pas installer systemd/Timers et pouvoir utiliser cron.
Bref, c'est plus la philosophie qui est derrière que je comprends pas, et quand je comprends pas quelque chose je m’agace.
(Bref)² , on parlait de Slackware au départ, et on / j’ai diverge/é … et ca fait beaucoups!
Heu … oui, ok la porte, je → []
voila
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Misc (site web personnel) . Évalué à 3.
Alors je vais me permettre de te pointer vers les discussions d'il y a 8 ans sur le sujet:
https://linuxfr.org/nodes/97210/comments/1426821
Tu peux, il suffit d'installer cron. Sauf erreur de ma part, les timers sont gérés en interne dans systemd (eg, dans le processus d'init), donc tu peux pas les retirer (tout comme tu peux pas retirer le support du dimanche dans cron). La raison est que mettre ça dans un processus à part n'apporterais rien à part de la complexité inutile (eg, communication entre le processus qui sert pour les timers et qui doit tourner à vide pour rien pour simplement signaler au systéme d'init de lancer un service).
Et je rappelle que les timers font des choses que cron ne fait pas de base, et je parle pas juste de la lisibilité. Mais par exemple, la limitation des ressources (utiles pour les backups), le fait de disperser les exécutions (utiles pour pas lancer 150 mises à jours à la même seconde), la gestion comme anacron pour le cas ou ta machine est éteinte, etc.
Et contrairement à vixie cron, la dernière release n'a pas l'age de voter en France depuis 1 mois.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par ff9097 . Évalué à 2.
Il ne fait pourtant qu'une chose : il gère ta machine
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par jyes . Évalué à 5.
Ah, je croyais c’était le rôle du noyau, … ah non, celui de Compiz, ou celui mon administrateur système. Je ne sais plus. « Gérer ma machine » c’est tellement clair comme définition.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par ff9097 . Évalué à 4.
Visiblement le second degré a du mal à passer ici aussi.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 14 mars 2022 à 09:26.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par Lutin . Évalué à 3.
Pourquoi pas tenter Gentoo ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 14 mars 2022 à 09:21.
Ce commentaire a été supprimé par l’équipe de modération.
# "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"
Posté par Christophe Duparquet (site web personnel) . Évalué à 2.
Un petit lien pour en savoir plus ?
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"
Posté par Yth (Mastodon) . Évalué à 10.
Bah c'est le ressenti de Patrick Volkerding, il s'agit ici d'une citation directe.
Elle est dans la ligne du traditionalisme Slackware qu'on pourrait traduire par : « fais chier de désapprendre un truc simple et qui fonctionne pour en apprendre un autre moins simple, même s'il fonctionne aussi ».
A saupoudrer de « ce que je connais est forcément plus simple que ce que je ne connais pas, si le service rendu est le même ».
[^] # Re: "le monde Linux s’éloigne lentement mais sûrement de la philosophie UNIX"
Posté par PR . Évalué à 1.
C’est dans le nom :
Mort aux cons !
# Distrowatch review
Posté par j (site web personnel) . Évalué à 3.
http://distrowatch.org/weekly.php?issue=20220214#slackware
[^] # Re: Distrowatch review
Posté par tisaac (Mastodon) . Évalué à 2.
Deux choses que je retiens ou plutôt qui m'interpelle:
L'hypothèse d'une communauté créée il a plus de 20 ans mais qui n'est depuis rejoint par pratiquement personne
Un KDE très économoe
Cela donne quoi sur les autres distributions ? J'avais en tête des ordres de grandeur bien plus important, style 800MB mais j'imagine que je me trompe, non ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Distrowatch review
Posté par Psychofox (Mastodon) . Évalué à 9.
J'ai 881MB d'utilisé sur une Fedora Jam KDE edition. Mon autre laptop sous Fedora avec Gnome utilise 1.2GB avec juste un terminal ouvert.
Cela étant dit, je crois que c'est pas vraiment le Plasma de slackware qui est léger mais tout le bordel qui se charge avant (et après pour la gestion des packets par exemple):
Vérifié sur un tty j'ai 600MB utilisé avant même de me logger sous kde, avec juste KDM ouvert sur la Fedora Jam et 660MB utilisés avec GDM avant de me logger sous gnome donc il y a déjà un usage mémoire conséquent avec systemd, networkmanager, et les quelques services par défaut (cups, firewalld, blutooth, chrony, polkit, power/thermal, etc). La différence entre mes deux laptops avant de me logger sur le bureau vient essentiellement de docker/containerd et openssh qui ne sont pas installé et activés sur ma Fedora Jam. Une autre VM sous Fedora avec i3 (+dmenu, i3bar, i3status) utilise 750MB avec juste un terminal.
Bref je crois que c'est l'absence de systemd et peut-être d'autres services non activés automatiquement qui fait la légèreté de ce bureau Slackware plus qu'une configuration particulière de Plasma.
[^] # Re: Distrowatch review
Posté par Yth (Mastodon) . Évalué à 10.
Je suis partagé sur cette évaluation, mais bon, je n'ai pas l'habitude de lire les trucs sur distrowatch…
Cette distribution a deux versions : une stable qui sort quand elle est prête (un peu comme Debian), et une rolling-release très active.
En 27 années et demi il y a eu 13 versions stables de Debian et 36 versions stables de Slackware.
On voit clairement un changement de rythme depuis la 14.1 (2,5 années) et la 14.2 (5,5 années), mais souvent il y a entre six mois et un an entre deux versions, pas « several years ».
Bon, c'est un brin agaçant quand on commence par des âneries, j'aurais pu lire un truc comme « on croyait que ça n'avançait plus vu que le rythme habituel a été dépassé de 5 ans, ce qui est très long en informatique », mais en vrai, jusqu'à la 14.1, c'était un projet plutôt rapide est dynamique.
Je ne peux qu'espérer que ça redevienne le cas.
J'ai encore une fois le sentiment que « ignorer les approches modernes de l'administration système » est juste une façon de dire qu'il n'y a pas systemd. On en pense ce qu'on veut, mais je ne vois toujours pas systemd comme un passage obligé, ni un truc si révolutionnaire que ça. Bref, passons…
Concernant l'installateur en mode texte, fichtre, mais et alors ?
C'est l'outil pour installer le système, le truc que tu vois une fois par nouvel ordinateur, le reste se fait en mise à jour, et on ne revoit plus jamais cet installateur.
Comme si, pour être « moderne », il fallait absolument avoir un outil à l'utilité marginale en version graphique ?
Alors que le seul intérêt d'un tel outil est de faire bonne impression pour un public de néophytes.
Que de préjugés alors…
Le gestionnaire de paquets de Slackware date des années 90.
Mais bon, dpkg date de 1994, RPM de 1997 (1995 en interne chez Redhat), ce sont aussi des gestionnaires de paquets datant des années 90.
Tous les trois ont évolués depuis, il y a eu des versions pour chacun d'entre eux, et il existe des outils plus haut niveau pour l'administration des paquets, pour les trois, y compris des interfaces graphiques (oui oui, même pour Slackware !).
Donc : critique ou gage de qualité ? Ou rien à voir avec la choucroute ?
Et la dernière phrase est juste, sous Slackware l'approche éditeur de texte dans un terminal est préférée à l'approche cliquesque, c'est à dire la façon de faire pour la majorité des serveurs : on n'accède pas à un outil graphique pour administrer un serveur, mais on le fait avec un vi/nano/joe quelconque à travers SSH.
Et même en 2021 on continue de faire des erreurs de copié-collé liés à des sauts de ligne probablement liés à l'utilisation de ce genre d'outils en ligne de commande via SSH… Je doute que Facebook utilise beaucoup de Slackware.
Encore une fois on n'a pas ici affaire à des outils très orientés néophytes.
Cela dit je ne critiquerait pas un outil de configuration graphique, mais sous Slackware il y a ce genre d'outils en ncurses, donc en terminal, mais graphique, dans la lignée de l'installeur, ils fonctionnent très bien via SSH.
Bref, à retenir : Slackware ne subit pas les hypes, suit sa propre voie, et privilégie l'apprentissage des fichiers de configuration à l'utilisation d'un outil graphique qui essaierait de centraliser tout, ce qui fait qu'on a une impression d'austérité et un franc manque de bling-bling.
Il y a pas mal de choses à l'avenant : si Slackware utilise un logiciel qui fait le taf, mais que d'autres plus grosses distribs ont remplacées par une alternative, qui fait le taf aussi, Slackware est considérée comme « en retard » plutôt que différente.
C'est très marquant avec l'opposition Calligra/LibreOffice.
Il y a des tas de gens qui se font chier à coder un logiciel efficace, léger, rapide, et parfaitement intégré à l'environnement KDE, j'ai nommé Calligra, mais comme le logiciel phare de bureautique c'est LibreOffice, point de salut, Slackware est à la ramasse de proposer le premier plutôt que le second !
Alors : il est très simple d'installer LibreOffice sous Slackware, et comme l'environnement de bureau par défaut est KDE (ou XFCE), Calligra est un choix par défaut assez évident : ça s'intègre bien, ça se lance vite, et ça fait l'essentiel du boulot, en odt/ods/od* comme LibreOffice, et c'est capable d'ouvrir des fichiers .docx comme LibreOffice.
Il faut vraiment avoir un usage un peu avancé de la suite bureautique pour trouver des différences fortes, ou des manquements, et dans ce cas là, tous les gens que j'ai rencontré avec ce genre de besoins, décrient LibreOffice est se tourne vers MS Office, à mon grand dam…
De la même manière, je n'ai rien contre VLC, mais critiquer son absence c'est un brin orienté…
Je n'aime pas spécialement utiliser VLC, réfractaire à l'interface, je préfère largement smplayer.
Historiquement, mplayer a toujours été le lecteur vidéo qui permettait de lire tout et n'importe quoi, avant le début du projet VLC, c'est toujours actif, toujours fonctionnel, ça marche au poil, encore une question de choix ici ? VLC ou la déshérence ?
Mouais, bref, il n'y a pas exactement les outils dont il a l'habitude et il est tout perturbé ?
Il y a du choix.
Autant pour la soi-disant austérité de la distribution : en full-install elle n'est pas minimaliste, et offre du choix pour un peu tout. En vrai, je trouve ça absolument génial pour un néophyte (que j'ai été), pour tout essayer, découvrir, apprendre, expérimenter.
C'est un peu ce que je ressens quand je dois me faire ch… avec une VM CentOS, pourquoi tant d'efforts pour des tâches simples ? pourquoi tant de commandes à retenir par cœur (ou à avoir dans sa cheat sheet) ?
Mais qui est le problème ? Moi, l'amateur d'une distribution fidèle, moderne et conservatrice à la fois, qui « fait les choses comme il y a 25 ans » qui suit campé sur mes habitudes, ou plutôt l'auteur de l'article qui a une vision des « bons logiciels à utiliser », des façons de faire, et ne comprends pas que Slackware puisse penser les choses différemment ?
Bref, je trouve cet article triste, très monoculturel, je trouve que l'auteur pousse à rejeter la Slackware non pas sur ses défauts, mais sur des choix qui ne sont pas jugés assez mainstream…
Un dernier point concernant la communauté, qui serait stagnante depuis 20 ans.
Ce n'est pas ce que je ressens dans le projet Slackbuilds, ça tourne, des gens vont, d'autres viennent, il y a plusieurs dizaines de contributeurs assidus et réguliers, et il n'est pas si commun de trouver un logiciel libre pour lequel c'est le cas.
Je le déplore mais il y a beaucoup plus de contributeurs au simple projet Slackbuilds.org qu'à Gimp, qui a, à mon avis, une importance nettement supérieure pour le monde des logiciels libres.
J'en suis ravi pour la Slackware, et les Slackbuilds, bien sûr, et je ne jetterai pas la vieille bique avec l'eau du temps, cette distribution a un avenir, et continuera de proposer une alternative fiable aux projets équivalents et plus mainstream que je trouve souvent trop pressés d'intégrer les dernières hypes du moment, au détriment d'autres projets tout aussi valables mais moins bien marketés.
[^] # Re: Distrowatch review
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Bof, c'est typiquement le genre d'articles qu'écriraient des usagers de Fenêtre qui se frottent pour la première fois à Nunux et qui ne veulent pas avouer leur incapacité… C'est aussi le genre de chose qu'on écrit quand on cherche à cracher à tout prix sur une distro qui n'est pas la sienne et considérée avec œillères que c'est la seule valable : qui veut noyer l'alternative l'accuse de tout et n'importe quoi. Aujourd'hui c'est VLC qui est à la mode, une autre fois on te dira que Amarok ou Clementine n'est pas installé donc qu'il faut jeter le bain avec le bébé. Texte tellement partisan que l'objectivité fini aux chiottes.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Distrowatch review
Posté par Crao . Évalué à 2.
VLC ça ne fait que 20 ans que c'est à la mode, d'ici 20 ans ce sera passé ;)
[^] # Re: Distrowatch review
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
(: Autant que l'excellent MPlayer
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# gestionnaire slpkg ?
Posté par benj13 . Évalué à 1.
Avis aux utilisateurs de Slakware…L'utilisation du gestionnaire de paquets "slpkg" est-elle une bonne idée selon vous ?
[^] # Re: gestionnaire slpkg ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Bah si ça existe, c'est que ça répond à un besoin. Faut surtout voir
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: gestionnaire slpkg ?
Posté par benj13 . Évalué à 1.
Simple curiosité ! Visiblement les utilisateurs Slackware s'en tiennent au gestionnaire d'origine.
[^] # Re: gestionnaire slpkg ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Moi oui :-) Et mes besoins sont simples (je ne rencontre pas de Slackware en entreprise où je travaille sur d'autres distros.) Je ne me prononce pas pour les autres, mais suis curieux aussi (d'où mes deux premiers points.) :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: gestionnaire slpkg ?
Posté par benj13 . Évalué à 1.
Avec l'avènement de Slackware 15 je m'essaie "gentiment" à cette distribution. Le fait quelle soit la doyenne et vos commentaires ont aiguisé ma curiosité. Étant donné que d'origine, le gestionnaire de paquets ne permet pas la résolution automatique des dépendances. Venant de distributions où cette fonctionnalité est de mise, je souhaitais avoir votre avis éclairé sur la question.
[^] # Re: gestionnaire slpkg ?
Posté par Yth (Mastodon) . Évalué à 5.
Mon avis sur la question des résolutions de dépendances est que je ne m'embête plus trop :
J'installe une Slackware complète - éventuellement sans les catégories kde ou xfce, voire xap et x pour un serveur - et hop, la résolution de dépendances est terminée : ça fonctionne.
Pour gérer le multilib (sur les machines où ça sert, en général c'est pour jouer), c'est le dépôt d'AlienBob, ajouté à slackpkg grâce à slackpkg+.
Ensuite pour les slackbuilds, je n'utilise pas de dépôt tiers comme Slacky ou AlienBob (sauf son excellent ungoogled-chromium pour les trois fois dans l'année où j'ai besoin d'un chrome-like), mais je compile moi-même, avec un outil comme sbopkg, pour gérer la file d'attente de construction, et les dépendances.
Cela dit slpkg est créé par un contributeur très actif du projet slackbuilds.org, et fait partie des divers outils recommandés pour gérer sa Slackware si on ne se contente pas de slackpkg.
Glossaire :
pkgtools : le gestionnaire de paquets bas-niveau de Slackware, celui qui permet d'installer, mettre à jour, supprimer, et lister les paquets Slackware.
slackpkg : gestionnaire de mise à jour automatique, qui va chercher les infos du dépôt Slackware sur internet, te liste les nouveaux paquets, les mises à jour etc, et permet de tout mettre à jour en une seule commande.
Slackbuilds : un fichier .SlackBuild est un script permettant à partir des sources d'un paquet de compiler et générer un paquet Slackware. Le projet slackbuilds.org maintient près de 8000 slackbuilds pour étendre sa Slackware dans tous les sens. La Slackware elle-même crée ses paquets à partir de SlackBuilds gérés par l'équipe. Slackbuilds.org part du principe que tu as une installation complète et à jour d'une Slackware stable : là-dessus tout le dépôt s'installe, et la gestion de dépendance ne prend pas en compte les paquets considérés comme présent via Slackware.
slackpkg+ : un plugin pour slackpkg permettant de gérer plusieurs dépôts de paquets, en plus du dépôt Slackware principal, comme par exemple multilib, alienbob, slacky, ou un répertoire personnel de slackbuilds produit soi-même, il permet aussi de lister les slackbuilds correspondant à une recherche par nom par exemple, mais sans gérer leur construction.
sbopkg, sbotools : Outils permettant d'automatiser la construction de paquets Slackware (avec dépendances) à partir du projet slackbuilds.org.
[^] # Re: gestionnaire slpkg ?
Posté par benj13 . Évalué à 2.
Merci pour ces éclaircissements ! C'est super sympa.
[^] # Re: gestionnaire slpkg ?
Posté par HL . Évalué à 3.
J'ai essayé
sbopkg
, et je le trouve plutôt bien fait.Entre autres, il mémorise les options de construction des paquets (pratique par exemple si on veut Wine à la fois en 64 et 32 bits), il gère les dépendances en générant des files d'attentes (queues) depuis les info de dépendances récupérés des Slackbuilds.
Si on a déjà utilisé les Slackbuilds avant (ce qui reste très simple), on sait ce que
sbopkg
fait on reste aux commandes de sa machine.A quoi ressemble
sbotools
?[^] # Re: gestionnaire slpkg ?
Posté par Yth (Mastodon) . Évalué à 3.
Désolé, je ne sais pas, j'utilise depuis 15 ans un outil bash maison pas super user-friendly, mais que je fais évoluer selon mon bon plaisir.
J'essaie de terminer la V3 en mode propre, en python parce que la maintenance des bonnes idées en bash est parfois cauchemardesque, et compatible avec certains formats de fichiers utilisés par d'autres outils d'admin slackware comme hoorex, mais ça n'avance pas vite…
Bref, je n'utilise pas certains outils dont je vante les mérites ^
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.